On this page we want to show you a very simple and convincing example of the power of Speagram's extensible parser in action.

Suppose that you already have a grammar which recognizes a certain set of objects and a parser which can take a text file and analyze it to perceive those objects in the file. Suppose further that for some reason — while still operating on the same class of objects — you would like to introduce some alternative shorthand notation. In other words, you want to extend the parser to be ready to perceive new ways of denoting the objects of the class described by the original grammar. Speagram allows you to do that once the grammar has been set without the need to come back to the specification of the grammar.

Let us briefly recall the definition of the class expression from the symbolic differentiation example.

        
Load state library:/basic.

New class expression.

New variable d as expression.
New variable e as expression.
New variable f as expression.
New variable n as natural number.

Natural number is an expression.
See last element as cast.

New element x as expression.

Expression + expression is an expression.
See (d+e)+f preferred to d+(e+f).

Expression * expression is an expression.
See (d*e)*f preferred to d*(e*f).
See (d*e)+f preferred to d*(e+f).
See d+(e*f) preferred to (d+e)*f.

Expression ^ natural number is an expression.
See d+(e^n) preferred to (d+e)^n.
See d*(e^n) preferred to (d*e)^n.

Close context.
        

Notice that with this definition we are not allowed to write 2x and expect the parser to perceive it as the expression 2*x. But since in Speagram we want to write as naturally as possible we want to allow ourselves the comfort of writing 2x^3 rather than 2*x^3. One way would be to extend the definition of the class with the following declaration:

New element natural number expression as expression.

But this would get us into a lot of problems. First of all, we would have to modify the differentiating function and the simplifying function so that they would recognize this new pattern. This would perhaps be a good exercise for you to write these modifications but it certainly would be an inelegant way to solve the problem. Another problem is that we would be artificially extending our class when in fact we are only dealing with a shorthand notation for something already existing in this class. On the conceptual level 2x and 2*x are the same and it would be against the art of writing conceptually clean programs to do it like this.

The correct solution is to keep the class definition as it is and instead write a function which will teach the parser to perceive 2x as 2*x:

 
Variable n as natural number.
Variable m as natural number.
Variable e as expression.
Variable f as expression.

New function natural number expression as expression.
See (n e)+f preferred to n (e+f).
See n (e^m) preferred to (n e)^m.
Let n e be n*e.
 

Notice that this solution preserves the simplicity of the class definition and no modification is required for the functions which were already written for this class. With the preferences defined you can comfortably use the notation.

See for yourself that Speagram parses expressions using the new syntax.

5x + 3x^2.